This invention relates to the field of multiphase transactions. In particular, this invention is drawn to distributed transactional processing.
Internet commerce applications are typically distributed applications with at least a three tier architecture. One tier handles presentation (e.g., the user interface), another tier handles the logic of the application, and yet another tier handles the data. Clients (e.g., browser software) handle the presentation. Application servers such as web servers handle the core logic of the application, but are otherwise stateless. A database contains the data and the state of the application. Application servers processes a client submitted request and store a resulting state in the database. The application server then returns a result to the client. This architecture has become prevalent with the advent of commerce on the Internet.
One advantage of partitioning the commerce applications into several tiers is that modularity provides for ease of management and scalability of the applications. Reliability in processing transactions is also needed to ensure that transactions are processed efficiently and with certainty. One disadvantage of the multi-tier architecture is that reliability is limited to xe2x80x9cat most oncexe2x80x9d request processing. Essentially, the request will be serviced at most once, if the request is processed at all.
A limitation of such a reliability standard is that the client-side software may not be able to distinguish between xe2x80x9callxe2x80x9d or xe2x80x9cnothingxe2x80x9d. If a failure occurs at the application server or database tier or a timeout occurs on the client side during processing, the end user receives an exception notification.
The exception notification does not indicate whether the requested transaction was performed or not. The user retries the request at the risk of inadvertently executing the transaction more than once. Thus reliability for each transaction is limited to an xe2x80x9cat most oncexe2x80x9d transaction processing and the client can issue multiple requests to obtain an xe2x80x9cat least oncexe2x80x9d assurance. Unfortunately, rather than an xe2x80x9cexactly oncexe2x80x9d result, the combination of submitting the same request multiple times with an xe2x80x9cat most oncexe2x80x9d reliability standard places the end user at risk of having the desired request being processed more than once.
Client transparency masks middle tier and database failures from the front-end client. One goal of client transparency is to ensure xe2x80x9cexactly oncexe2x80x9d processing by automatically retrying transactions at the appropriate server level when the transactions abort due to failures at the server or database tiers.
One technique for client transparency relies on the assurance that a single server handles a selected request. This may not be a practical approach in an environment where multiple application servers may be concurrently working on the same request. Additional transaction tracking overhead is required in fault tolerant system to ensure that the primary server(s) handling a transaction have indeed failed, thus delaying the backup server take-over process. The failure detection process must be perfect in order to ensure that only one of the primary or the backup server is handling the request. Delaying the backup server take-over may result in a substantially increase in the number of potentially at-risk transactions due to the asynchronous nature of the requests.
One three tier architecture uses a transaction processing monitor to enable clients to abort a transaction if a reply value is not received from the second or third tiers after a pre-determined time interval. The client, however, does not participate in the commitment of transactions. If the second or third tier transaction manager fails, the outcome of the transaction may be unknown to the client.
Another solution is to include the client as a participant in order to ensure the outcome is communicated to the client. One disadvantage of this approach is that xe2x80x9cthin clientsxe2x80x9d such as browsers may not have the resources needed to support participation. Furthermore, additional communication is required between the client and the second tier because the client will be involved in the two-phase commit process. Finally, as a participant, the client becomes a potential point of failure for the two-phase commit process required across the transaction participants.
Methods and apparatus for performing three tier asynchronous client transparency are described. A method for processing at the client tier includes the step of sending a request and a count from a client to a first application server of an application server group. The request and count are resent to the application server group, if no corresponding decision comprising a result and an outcome is received within pre-determined time period. The request is resent with an incremented count to a selected one of the first application server and the application server group, if a corresponding decision comprising a result and an outcome indicates that the result has not been committed. The result of the decision is provided to an end-user, if the outcome indicates that the result has been committed.
A method for processing at the application tier includes the step of receiving a request originating from a client tier. An attempt to write a first application server identifier to a write-once register entry associated with the request is made in response to receipt of the request by the first application server. A result is computed for the request. An outcome is determined for the result. An attempt to write the result and outcome as a first decision to the write-once register entry is performed. An attempt to terminate a transaction identified by the write-once register entry in accordance with a second decision indicated by the write-once register entry is then performed.
A method of handling transactions for application servers suspected of failure includes the step of selecting an active transaction of a suspected application server of an application server tier. An attempt is made to invalidate the transaction by writing a decision with an aborted first outcome to a write-once register entry associated with the selected active transaction. Commands are issued to a database tier to terminate the transaction in accordance with a second outcome indicated by the write-once register entry.
Other features and advantages of the present invention will be apparent from the accompanying drawings and from the detailed description that follows below.